Instant messaging (IM) is a form of communication that has grown in popularity in recent times. IM is conventionally supported by a client application running on a user device, for example a smartphone or a computer terminal. The client application presents a user interface from which a user can generate messages for transmission to other users, and view messages received from other users. When a message is to be transmitted the client application can cause the user device to transmit that message to one or more remote servers operated by the organisation that provides the IM platform in question. Those servers then direct the message to the client application of the intended recipient. IM messages are typically transmitted over internet protocols.
Typically, a user communicates via IM by first logging into an IM account by means of the IM client application. Once logged in, the user can see which of his/her contacts are also logged in. This information is derived from the servers of the IM provider. The user can communicate with one more of those users. Some IM clients allow the user also to transmit messages to contacts not currently logged into their account, who can then view the messages once they are logged in.
One particular feature of IM messages is that they pass via a dedicated backend operated by the organisation that provides the IM platform in question. A single organisation may provide multiple distinct IM clients that can be used on a single user device. Although the IM clients may be distinct in the sense that a user uses each client individually, that they present themselves as distinct applications on the user's terminal and that they have different user interfaces which may present different branding, the clients may nevertheless operate according to the same underlying technical framework, or engine. They could each comprise or use identical software for handling their messaging functions. They could also share the same backend servers. This may provide certain advantages for the organisation such as reducing cost by minimising the amount of software engineering and backend architecture required. A user of one such IM client may also benefit from being able to send messages to a greater number of contacts by having access to individuals who use any of the IM clients supported by the shared backend instead of being limited to just the contacts who use the same IM client as the user.
However, implementing multiple distinct types of IM clients using a shared or common backend may have the drawback that the distinct types of IM clients begin to conflate. For example, if a user device is running more than one type of IM client, IM messages received at the user device might be received by each type of the client running on that device. Alternatively, a message communicated by one user device using one type of client could potentially be received by the recipient user device on another type of client. This could happen for example if the two user devices do not both use a common client.
As well as being frustrating for the user, this conflation of the IM clients may be undesirable for privacy or confidentiality reasons. If an IM client is dedicated to a particular purpose, for example communicating financial information, a user would likely wish to ensure that any communicated message was only received by the same type of client at the recipient devices, and to not be received by user devices that are not running that type of client at all.
There is therefore a need for an improved way of communicating with users with electronic devices supporting multiple IM clients.